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con POV 




Por estas paginas ya han pasado diversas utilidades de alzado de 
terrenos (la ultima fue Hf-lab). Todas estas herramientas producen 
objetos de apariencia montanosa utilizando tecnicas fractales. Pero, ^que 
hacer si uno esta interesado en incluir zonas "reales" en una escena? La 
respuesta a esto son los ficheros .Dem (Digital Elevation Model), que 
guardan datos de alturas de zonas terrestres reales y pueden -mediante 
utilidades- ser "traducidos" a archivos tga procesables por «POV». 
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1 usuario puede en- 

Econtrar ficheros 
.dem en muchos si- 
tios, pero sin duda 
el mas importante 
es el Web del USGS 
(United States Geological Survey); un 
organismo a traves del cual pueden 
conseguirse mas de 700.000 fotos ae- 
reas de nuestro planeta. Podemos co- 
menzar en: http://info.er.usgs.gov 

...y podemos buscar mapas en: 
ftp://edcftp.cr.usgs.gov/pub/data 

Otro "site" muy util es: www.ems.uw- 
platt.edu/ce/fac/dymond/giswww.htm 

En este ultimo lugar encontraremos 
una coleccion de sitios Gis recopilados 
por un tal R. Diamond, (las siglas Gis 
corresponden a "Geographic Informa- 
tion System" y aluden a un sistema de 
information disefiado para tratar infor- 
maticamente coordenadas geograficas. 
Sin embargo, en el faq gis-faq.txt -que 
incluimos en el CD-ROM- se indican 
un monton de definiciones mas de las 
que parece desprenderse, que GIS es 
tanto una serie de bases de datos como 
un conjunto de procedimientos y nor- 
mativas para procesar estos datos). 

Pero volviendo al Usgs, este orga- 
nismo tiene archivos .dem que cubren 
la totalidad del continente americano 
con una resolution de un valor de altu- 
ra para cada 30 metros. Pero partiendo 
de estas direcciones, podemos hallar fi- 
cheros dem que cubren todas las zonas 
planetarias, informacion geologica, uti- 
lidades relacionadas con los datos ofre- 
cidos, bitmaps de otros planetas del sis- 
tema solar y muchas cosas mas. 

En cuanto a la palabra dem, es em- 
pleada en muchos sitios como un ter- 



mino generico que alude a todos los ti- 
pos de ficheros donde se almacenan da- 
tos de elevaciones de zonas geografi- 
cas. Sin embargo, aquf lo emplearemos 
para referenciar a los ficheros de for- 
tnato dem distribuidos por el Usgs. 

Los archivos dem estan en formato 
ascii y son arrays de datos donde se 
guardan valores de altitud para distan- 
cias espaciales regulares de zonas geo- 
graficas reales. (es decir, los satelites 
aplican una rejilla imaginaria sobre el 
terreno y toman un valor de altura para 
cada intersection de esta rejilla). La 
ptegunta ahora es: <,como podemos 
emplear un archivo .dem desde POV? 

Dem2pov 

Dem2pov es una utilidad escrita por 
Bill Kirby partiendo de otra utilidad de 




conversion mas general. Dem2pov lee 
ficheros .dem y produce archivos en for- 
mato tga que podran ser lei'dos y emple- 
ados por la sentencia Heightfield de Pov. 
El programa funciona bajo DOS y re- 
quiere al menos un 386. La invocation 
mas corriente para este programa es: 

dem2pov fichero_entrada.dem fi- 
chero_salida.tga 

Sin embargo, antes de generar el fi- 
chero tga que emplearemos mas tarde 
desde POV. Dem2pov nos hara una se- 
rie de preguntas cuyas respuestas afec- 
taran al archivo a producir. Para estas 
respuestas podremos apoyarnos en una 
serie de datos que forman parte de la 
cabecera del .dem y que Dem2pov im- 
primira en el monitor antes de formular 
las preguntas. Tambien. si lo deseamos, 
podremos ordenarle al programa que se 
limite a mostrarnos dicha cabecera. sin 
generar ninguna tga (para ello le indi- 
caremos tan solo el fichero .dem de en- 
trada). Ademas. es posible guardar esta 
cabecera en un archivo con una opera- 
tion de redirection de ficheros como: 

dem2pov fichero_entrada.dem > 
fichero_datos.txt 

Pero regresemos al caso mas ti'pico. 
Despues de mostrarnos los datos de la 
cabecera, el programa nos mostrara el 
mensaje "0 for all, 1 for samples, 2 for 
subset". Con ello el programa nos ofre- 
ce tres alternativas: si respondemos 
"0", Dem2pov entendera que desea- 
mos emplear todos los valores de altu- 
ras del dem. (Este es el caso mas fre- 
cuente). Con "1" el programa creara 
una tga "a escala" tomando solo uno de 
cada x valores de altitud. Este escalado 
no tiene por que ser proporcionado ya 
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que, si escogemos esta op- 
tion, despues se nos pedira 
que introduzcamos el "colum 
sample interval" y el "row 
sample interval". Es decir, los 
intervalos para las columnas 
y las filas. Si damos un valor 
de 5 para ambos casos, por 
ejemplo, el programa solo 
tendra en euenta un valor de 
altura de cada 5, lo cual quiere decir 
que la tga resultante sera 25 veces mas 
pequena. Finalmente, el caso 2 se em- 
plea para crear una tga usando solo una 
parte del dem y desechando el resto de 
los datos de altitud. Aquf se hace preci- 
so explicar que los datos de alturas del 
dem se ordenan en columnas y filas, 
empezando la primera columna en el 
borde oeste del mapa y la ultima en el 
lado este. Dentro de cada columna los 
datos empiezan en el Sur del mapa y 
acaban en el Norte. Sabiendo esto po- 
dremos especificar el area del dem a 
partir de la cual va a crearse la tga dan- 
do valores a las siguientes h'neas; "start 
column" (primera columna), "end co- 
lumn" (ultima columna), "start row" 
(primera fila) y "end row" (ultima fila). 
En la siguiente pregunta el progra- 
ma nos pedira que indiquemos el tipo 
de heightfield a crear. Los valores acep- 
tables son para los "Actual heights" y 
1 para los "Normalized". Si nos decidi- 
mos por el primer caso, el programa 
nos pedira despues (con "vertical sca- 
ling factor") un valor que sera emplea- 
do como factor de conversion entre 
unidades de medida (por ejemplo usa- 
rfamos 3.281 para pasar de metros a 
pies). En el otro caso, la cuestion es al- 
go mas complicada: la cabecera del 
Dem devuelve dos valores que son los 
valores de minima y maxima altitud del 




fichero. Si escogemos el heightfield 
"normalizado" el valor maxima de alti- 
tud quedara a la altura 1 en el height- 
field de POV (si no se hacen "scales"). 
El resto de los puntos a calcular toma- 
ran sus valores de altitud teniendo en 
euenta el siguiente factor: 

factor= 65535 / (Elevacion_ 
maxima + Bias) 

El valor 65535 es el numero de gra- 
daciones de altura posibles que permi- 
ten los heightfields que emplean tgas. 
La variable "Bias" sera la siguiente que 
daremos por teclado. Se trata de un va- 
lor que se sumara o restara a los valores 
de altitud dependiendo de su signo. Pa- 
ra comprender como funciona esto 
consideremos los siguientes ejemplos 
tornados del fichero Kirkland.dem (que 
se incluye con la 
utilidad): el valor 
de altitud minima 
de este fichero es 
de 1 158 metros y 
el de la maxima 
de 1820 metros. 
Si generamos la 
tga escogiendo la 
option de norma- 
lization y dando 
un valor de para 
laescalay el Bias, 
el valor de altura 



para el punto mas bajo sera 
de 0.6326 y de 1 .0 para el 
punto mas alto. Si, en vezde 
esto, damos un valor de - 1 1 58 
al bias, entonces los resulta- 
dos seran de y de 1 respecti- 
vamente para la altitud de los 
puntos mas bajo y mas alto. 
Esto quiere decir. por supues- 
to, que, como podemos ver en 
las fotos hftest3 y hftest4 (pagina ante- 
rior), la forma final del objeto se vera 
afectada. La base del objeto queda en 
el mismo sitio para ambas pruebas pe- 
ro, en el caso del bias=-l 158, parece 
que el objeto se ha estirado hacia abajo. 
Finalmente, el programa nos pedira 
el valor de "default elevation (final out- 
put units)". Nosotros no acabamos de 
comprender la funcion de este parame- 
tro. Segun el doctorial se emplea para 
dar valores de altitud a los puntos del 
Heightfield para los que no haya valo- 
res dem ((,?). En las pruebas se ha deja- 
do siempre a 0. 

Los ficheros de ejemplo 

Al descomprimir Dem2pov.zip, nos 
encontraremos el ejecutable de la utili- 
dad, el codigo fuente (dem2pov.c), va- 




4 Rendermam'a 



rios ficheros utilizados para compilar 
dichos fuentes en distintos compilado- 
res, un fichero .pov para hacer pruebas 
(hftest.pov) y un zip con un archivo 
dem de ejemplo (kirland.zip). Como 
veremos, una de las li'neas del fichero 
.pov escala el objeto heightfield que se 
creara. Este detalle tendra la virtud de 
dar distintas proporciones al objeto, 
con lo cual quedara alterado el propo- 
sito inicial de renderizar un trozo de te- 
rreno real. ;,Por que? Si los lectores 
quieren generar terrenos iguales a los 
almacenados en los archivos dem, la 
escala tendra que ser uniforme en los 
tres ejes (Nota: estamos dando por sen- 
tado que conoceis perfectamente el 
funcionamiento correspondiente a la 
sentencia Height_field de POV; si este 
no es el caso puede hallarse una des- 
cripcion de la misma en el articulo 
"Como crear terrenos..." del numero 8 
de Rendermanfa). 

El problema de la textura 

Quiza el problema mas importante 
que presenta cualquier Heightfield es 
el de la textura a aplicar. Si nos limita- 
mos a dar un color liso al objeto, este 
no tendra una apariencia demasiado 
real. Las montanas del planeta tierra no 
suelen exhibir un color uniforme. Pe- 
ro, afortunadamente, la realidad puede 
simularse aplicando un mapa de colo- 
res sobre el objeto (como recordaran 
los povmanfacos, la sentencia co- 
lor_map nos permitira definir una gra- 
dacion suave de colores sobre un obje- 
to). Sin embargo, esto no sera facil. 
Primero habra que definir un buen ma- 
pa de colores y luego habra que apli- 
carlo adecuadamente (podemos ver lo 
que sucede si el objeto esta desplazado 
o incorrectamente escalado con respec- 



to al mapa de co- 
lor mirando las 
imagenes hftest3 
y hftest4). 

Las 

montanas de 
Bryan Beaty 

Bryan Beaty es 
un pov-usuario 
que suele utilizar ficheros dem para ge- 
nerar estupendas imagenes sinteticas. 
Hay que destacar, sin embargo, que 
una buena parte de ellas no estan he- 
chas con POV, sino con utilidades crea- 
das por el propio Beaty. En efecto, este 
autor ha creado una serie de utilidades 
para manipular los archivos dem de di- 
versas maneras. Segun afirma el mis- 
mo Beaty, el primer paso consiste en 
traducir el dem a emplear a un formato 
mas compacto y facil de manipular (los 
archivos dem estan en formato ascii y 
pueden ser muy grandes. Ademas, es- 
tos ficheros pueden tener muchas posi- 
bles cabeceras y especificaciones que 
hacen bastante fastidiosa y complicada 
la tarea de escribir utilidades para ellos. 
Hemos visto muy pocas utilidades para 
este tipo de archivos). 

Por estas razones Beaty comienza 
empleando una utilidad escrita en C++ 
por el mismo y que genera un fichero 
en formato Tpatch a partir del Dem ori- 
ginal. Este fichero Tpatch utiliza un 
formato inventado por el mismo Beaty 
que codifica cada dato de altitud en 2 
bytes (lo cual representa un importante 
ahorro en el tamano del fichero). 

En el siguiente paso Beaty emplea 
otra utilidad que lee el archivo tpatch 
generado previamente y dibuja una 
imagen del terreno empleando un algo- 
ritmo propio. Las imagenes son vistas 




aereas muy similares a las que pode- 
mos ver en los mapas ffsicos de cual- 
quier Atlas. Segiin afirma el autor, esta 
utilidad genera la imagen empleando 
tres operaciones fundamentales: la in- 
terpolacion, la codificacion del color y 
el sombreado. En el primer paso, la in- 
terpolacion puede ser necesaria si la 
imagen final a generar tiene una reso- 
lution superior a la del dem empleado 
como punto de partida. En este caso la 
utilidad generara puntos adicionales 
utilizando la interpolation entre los 
puntos originales. Despues viene la co- 
dificacion del color. Esto viene a ser al- 
go equivalente al mapa de colores de 
POV. Los picos de las montanas tienen 
un color bianco, las zonas algo mas ba- 
jas del mapa se colorearan con tonos 
marrones y amarillos. y las tierras bajas 
con colores verdes. Finalmente, en el 
sombreado, se utiliza la inclination de 
las normales de cada triangulo para de- 
lerminar la cantidad de luz que recibira 
dicha cara con respecto a una fuente de 
luz situada de forma arbitraria al 
norte del terreno. 

Para Beaty, sus imagenes tienen mas 
de arte que de mapas, lo cual queda de 
manifiesto, sobre todo en la imagen que 
ha servido de portada a este articulo y 
que Beaty creo empleando POV (el site 
de Bryan Beaty esta en www.oas.om- 
ron.com/bryan/anims.html). 
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Lnsflare.inc 



LnsFlare 3.0 de Nathan Kopp es probablemente la mejor utilidad 
disponible hoy dia para generar luces flare con POV. Se trata de otro 



fichero include disenado para P< 



.0 y escrito -como no- empleando 



y fantastical sentencias del lenguaje escenico de POV. Con 



los povad 



brillos de las camaras, luc 



hi simular cosas tales como los tipicos 
iones estelares, el brillo de 



las toberas de un cohete, etc. jPovmaniacos/as, pasen y deslumbrense! 



uien haya lefdo los 
artfculos anteriores 
sobre Trees. inc y 
Books. inc se hara 
una idea de como se 
trabaja con este nue- 
vo "Ipas" de POV. Como ocurre con los 
mencionados ficheros, Lnsflare se ma- 
neja asignando valores a diversas varia- 



bles para, finalmente, colocar una orden 
"#include" que cargara el flare en nues- 
tra escena. La cantidad de parametros 
que se requiere para definir un flare es 
bastante grande pero LnsFlare trae ya 
definidos 20 tipos de flares distintos. 
Con lo que bastara con declarar algunas 
variables e indicar el tipo de flare para 
colocar el "objeto" en nuestra escena. 



Nuestro primer flare 

Para situar un flare en una escena he- 
mos de seguir una serie de pasos. En 
primer lugar hay que indicar a LnsFla- 
re donde se encuentra la camara, lo 
cual se hard asignando a la variable 
camjoc la misma position que va a te- 
ner la camara. De hecho, lo mas practi- 
co es hacer algo como esto... 
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Luces flare para POV 



#declare eamjoc = <x,y,z> 
camera) 
location eamjoc 



Obrar asi nos resultara lo mas como- 
do, ya que solo tendremos que cambiar 
un vector cuando vayamos a cambiar 
la posicion de la camara. Igualmente 
deberemos obrar con la variable lookat, 
con la que indicaremos la posicion ha- 
ck la que esta mirando la camara (vec- 
tor look_at), y con la variable lightjoc. 
en la que senalaremos la posicion de la 
fuente de luz que va a ser "flareada". 
Tambien hay que indicar el vector don- 
de queda el cielo (para la camara) en el 
identificador "sky_vect". Esto, en una 
escena tfpica donde el suelo correspon- 
de al piano X-Z debera hacerse con 
"sky_vect=y". 

Y por ultimo, tan solo nos restart in- 
dicar el tipo de flare para la escena 
y colocar la sentencia include. Vea- 
mos un ejemplo; 



#declare flare_type = "35mm" 
#include "lnsflare.inc" 



El array "35mm" asignado a la va- 
riable "flare_type" es el nombre 
de uno de los flares que vienen 
definidos en LnsFlare. 



Experimentos 

En tierraO.pov hay definido un flare 
del tipo "105mm" situado a 122.000 
unidades de la camara. La imagen re- 
sultante es la de una especie de estrella 
azulada de la que parten varios rayos 
de luz. Nuestro primer experimento 
consistira en alejar este pequefio sol su- 
mando un par de ceros a la variable 
"lightjoc". El resultado de renderizar 
esto, sin embargo, no ofrecera cambios 
con respecto a la imagen anterior. Esto 
ocurre asi porque los flares son, en rea- 
lidad. discos sobre los que se aplica una 
textura con la "luz". El flare, en la ima- 
gen. parecera estar en la misma posi- 



cion 3D de la fuente luminosa cuya ubi- 
cacion hemos dado en "lightjoc", pero 
pronto comprenderemos que realmente 
no esta en el mismo sitio ya que. sin im- 
poitar cuanto alejemos a la fuente, el fla- 
re seguira teniendo el mismo tamano. 

Esto nos vendra muy bien porque 
podremos dedicarnos a manipular el 
aspecto del flare sin que importe su ta- 
mano real ni la distancia a la que se en- 
cuentre. Tenemos que pensar en el flare 
como un efecto que se situa sobre la 
fuente de luz, no como un objeto nor- 
mal (es de suponer que la posicion final 
del flare se calcula automaticamente a 
partir de la posicion 2D de la fuente en 
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la imagen. Las flares de 
Polyray se anadfan una vez que la ima- 
gen estaba calculada pero LnsFlare no 
necesita haceresto). 

Podemos comprobar esto realizando 
otro experimento: en tierra 1 .pov se ha 
afiadido al planeta Tierra en el centro 
de la imagen. La Tierra esta mucho 
mas cerca de la camara que la fuente 
de luz y deberfa, por tanto, ocultarla. 
Pero no ocurrira asi y seguiremos vien- 
do el flare, como antes. Esto, natural- 
mente, se debe a que estamos viendo 
un efecto cuya posicion se ha determi- 
nado a partir de la direccion de la fuen- 
te de luz a la que hemos atado dicho 
efecto. No estamos, insistimos. viendo 
una fuente de luz sino un efecto. 

Desde luego esto puede resultar fas- 
tidioso en ciertos casos puesto que pue- 
de interesarnos que el espectador su- 
ponga que el flare es. como parecia al 
principio, una fuente estelar. Suponga- 
mos que estamos realizando una ani- 
macion en la que precisamente hay un 
sol y un planeta. Tendn'amos que tener 



cuidado de que el planeta no se inter- 
pusiera entre el sol y la camara, ya que 
entonces quedarfa claro que el flare no 
es mas que un efecto. Pero, por suerte, 
Kopp penso en esto ya en la version 2.0 
e implemento la posibilidad de ocultar 
el flare. Veamos como se hace esto: an- 
te todo hay que decirle a LnsFlare don- 
de esta el mundo que va a ocultar al fla- 
re y el radio del planeta: 

#declare planetjoc = <X,Y.Z> 
#declare planet_rad = Rmundo 

El vector indicado en planetjoc de- 
ne la posicion del planeta y "Rmundo" 
es el radio del mismo. Tambien habre- 
mos de indicar el radio de la fuente 
asociada al flare con... 

#declare light_rad = Rluz 

Si hecho esto renderizamos de nuevo 
veremos que POV imprime un mensaje 
diciendo que la fuente de luz queda de- 
tras de la camara o detras de un planeta. 



y que el flare no se ha creado. Sin em- 
bargo, si alteramos el valor de la varia- 
ble lightjoc de tal modo que la fuente 
no quede oculta por el planeta aunque 
si cerca de algiin punto de su perfil, en- 
tonces POV imprimira un mensaje di- 
ciendo que sera visible un porcentaje 
del flare. De esto parece deducirse 
(aunque no hemos realizado la prueba) 
que podrfamos realizar una estupenda 
animacion en la que un sol apareciera 
de detras de un planeta. 

Kopp tambien ha previsto el poder 
hacer lo mismo con un piano, de ma- 
nera que podamos representar una 
puesta de sol. Para ello emplearemos 
las variables siguientes; 

#declare planeloc = <x.y,z> 
#declare plane_norm = <x,y.z> 

"Planejoc" guarda las coordenadas 
del piano y "plane_norm" su normal 
(Nota: por ahora solamente puede es- 
pecificarse un planeta o un piano que 
oculten al flare). 

Manipular flares 

Los flares de este "ipas" estan com- 
puestos por partes cuyas caracterfsticas 
podemos alterarcambiando los valores 
dados por defecto. En primer lugar te- 
nemos el flare inicial o primario. Este 
consiste en un brillo central con el que 
el espectador identificara a la fuente. 
Luego, extendiendose a partir de este 
flare inicial, tenemos una zona semi- 
transparente (glow) cuyo resplandor va 
decreciendo a medida que nos aleja- 
mos del flare primario. Esta zona pue- 
de extenderse incluso mas alia del ani- 
llo. Despues tenemos un anillo (ring) 
que engloba al flare inicial (y normal- 
mente tambien al glow). Ademas, nor- 
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malmente suele haber unos destellos 
(sparkles) que parten del flare primario 
y, opcionalmente, unas bandas (stre- 
aks) que atraviesan el flare inicial (y 
que suelen asociarse a las explosiones 
estelares o a los brillos de los focos). 

Aquf acaba lo que podeinos consi- 
derar como la parte principal del flare. 
Luego siguen otros flares secundarios 
a los que llamaremos flare 
spots y flare dots. Ambos 
se dibujan formando una 
lfnea que cruza el flare 
inicial (en lightjoc) y el 
punto central de la ima- 
gen (definido en lookat). 
Los flare spots son los 
empleados por defecto. 
Tienden a ser mas trans- 
parentes en el interior que 
en sus bordes y por ello 
son llamados a veces ring 
spots. En los otros sucede 
exactamente a la inversa y 
tambien se distinguen por 
ser (por defecto) mas pe- 
quefios que sus hermanos. 

Veamos ahora como f'unciona todo 
esto. Kopp ha incluido en el archivo la 
definition de una veintena de flares que 
nos serviran para muchos casos dife- 
rentes. Ya hemos visto como usar estas 
flares predefinidas pero, en la practica, 
es casi seguro que el usuario intentara 
crear enseguida sus propias flares em- 
pezando, quiza, por especificar un tipo 
concrete para realizar experimentos so- 
bre el. jCraso error! La sorpresa del 
pov-adepto resultara mayuscula al 
principio, cuando se percate de que sus 
cambios en las variables de tamafio, co- 
lor y otras, no tienen el menor efecto. 
No obstante, la explication es muy 
sencilla: Kopp no ha empleado las sen- 




tencias #ifndef de la manera que po- 
drfamos suponer, colocando #ifndefs 
en todas las variables de cada tipo de 
flare. De haberlo hecho asf podrfamos 
declarar las variables del flare, y luego 
invocar al tipo deseado con la seguri- 
dad de que los cambios tendrian efecto. 
Esto sen'a lo mas facil pero podemos 
olvidarnos de ello. La iinica manera de 
conseguir cambios en un flare predefi- 
nido es, pues, cambiar las variables co- 
n'espondientes en LnsFlare.inc. 

Pero hay una excepcion a esto. Si 
eliminamos la declaration de la varia- 
ble "flare_type", LnsFlare entendera 
que queremos emplear el flare por de- 
fecto, el cual si utiliza #ifndefs en to- 
das sus variables. La solution pasara 



pues por no emplear 
flare_type y copiar los de- 
clares del flare sobre el 
que pretendamos experi- 
mentar. A menos, claro es- 
ta, que pretendamos era- 
pezar desde cero o alterar 
al propio flare por defecto. 

Variables 

de control 

del flare primario 

Sabido esto ya estamos en condicio- 
nes de empezar a estudiar las variables 
de LnsFlare.inc. En primer lugar tene- 
mos las que afectan a las dimensiones 
del Flare. Estas son source_size, 
glow_size, ring_size y ring_width. La 
primera afecta a las dimensiones del 
flare primario y su valor es, por defec- 
to. de 0.02. Las siguientes son, respec- 
tivamente, las dimensiones del glow, 
del anillo y del ancho del anillo. Es im- 
portante aclarar que estos valores son 
relativos al tamafio global de la pantalla 
y que es por esta razon por la que el fla- 
re no crece ni disminuye de tamafio 
cuando la camara o la fuente se alejan. 
Solo hay una excepcion para esto: si 
cambiamos el valor "telescopico" de la 
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sentencia "direction" de la camara (que 
se emplea para hacer zooms), entonces 
el tamano del flare sf quedara afectado. 
Ahora veamos las variables que con- 
trolan el color. Las de control directo 
son source_color, glow_color y 
ring_color. Como ya imaginara el lec- 
tor, controlan respectivamente el color 
del flare primario, del glow y del anillo. 
Otras variables como source_bright y 
glow_bright son factores que se em- 
plean para multiplicar el brillo del flare 
primario y su glow, controlando asf su 
maximo nivel de brillo. Sin embargo, 
estas ultimas variables no produ 
ciran efectos visibles si el co- 
lor asignado ya estaba a su 
maximo valor de lumi- 
nosidad. Otras varia 
bles que afectan al 
flare son las que 
controlan el nivel 
de translucencia. 
Estas son sour- 
ce_tr, glow_tr y 
ring^tr que afec- 
tan respectiva- 
mente al nivel 
mfnimo de trans- 
lucencia del flare 
primario, del glow y 
del anillo. 

Destellos (Sparkles) 

Los destellos son brazos ra 
diales que parten del flare primario. 
Los hay de dos grupos: en el primero 
los brazos son mas largos que los del 
segundo grupo, siendo los destellos de 
este ultimo mas numerosos que los del 
primero. La longitud de estos brazos se 
define en las variables star_size (primer 
grupo) y star2_size (segundo grupo). 
El numero de destellos se indicara en 



num_arms y num_arms2. el ancho de 
los brazos se especificara en star_width 
y star2_width y su color en star_color. 
Otras variables importantes son starjr, 
que controla el nivel mfnimo de trans- 
lucencia. star_seed, que guarda un va- 
lor de semilla para la aleatoriedad en la 
colocacion de los destellos, y 
crisp_star, que causa el que los deste- 
llos del primer grupo tengan bordes de- 
finidos (ver el flare "concert"). Por su- 
puesto podernos 




eliminar 

los destellos poniendo num_arms y 

num_arms2 a cero. 

Flare spots y dots 

Las caracteristicas de los flares se- 
cundarios son controladas mediante 



una serie de variables que describire- 
mos a continuacion: Spot_size contro- 
Iara el tamano standard que se aplicara 
para estos flares y spot_color guardara 
su color normal (luego veremos el por- 
que de la palabra "normal"). Spot_tr 
guardara la translucencia minima del 
spot y num_spots indicara al "ipas" el 
numero de flares secundarios que se di- 
bujaran a cada lado del flare primario. 
La separacion entre los flares depende- 
ra en principio de la distancia entre el 
flare primario y la position observada 
pero podernos influir sobre dicha se- 
paracion con un par de variables; 
;pot_dist y spot_dist_pwr. 
La primera es un factor 
pero, en el momento de 
escribir estas Ifneas, 
no comprendemos 
aun su funciona- 
miento exacto. 
En cuanto a la 
segunda, deter- 
mina si el creci- 
miento de las 
distancias de los 
flares secunda- 
rios con respecto 
al primero es lineal 
(valor l)ocuadrati- 
co (valor 2). Otra va- 
riable interesante es 
skip_spots con la que indi- 
caremos el numero de spots que 
pueden omitirse (y que seran los 
mas cercanos al flare primario). 

Ahora vamos con un detalle muy in- 
teresante. Las variables descritas hasta 
ahora afectaran por igual a todos los 
spots con lo que el resultado final sera 
excesivamente uniforme. Para reme- 
diar esto y dar algo de alegria al con- 
junto disponemos de algunas variables 
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que introduciran un factor de aleatorie- 
dad en los flares secundarios. Estas va- 
riables son spot_size„rand, spot_co- 
lor_rand, spot_dist_rand y spot_seed. 
Los valores (de a 1 ) que demos a es- 
tas variables se entenderan como un 
porcentaje de desviacion con respecto a 
los valores "normales" definidos por 
las variables de tamano, color y distan- 
cia que ya hemos visto. Por ejemplo. 
un valor de 0.2 en spot_size_rand im- 
plicara que el tamano de los flares se- 
cundarios oscilara entre un 80% y un 
120% con respecto al definido en 
spot_size. Spot_seed es, por supuesto. 
la semilla con la que alimentaremos al 
generador pseudoaleatorio. 

(,Y cuando se dibujan los flare dots? 
Bien, para eso esta la variable llamada 
percent.dots, donde indicaremos un va- 
lor de a 1 con el porcentaje de flares 
secundarios que deseamos que sean 
flares dot. Estos flares tienen su propio 
grupo de variables; dot_size, dot_color 
y dot_tr, cuyo significado ya habra adi- 
vinado el lector. 

jPero aiin hay mas! A partir de la 
version 2.1, Kopp afiadio la posibilidad 
de que los flares se visualizaran como 
hexagonos. Como anteriormente, para 
determinar el porcentaje de flares que 
deberan verse asi, existe una variable 
determinada; percent_hex. Las carac- 
teristicas de estos flares seran contro- 
ladas con las variables que empiezan 
con la palabra spot. 

Bandas de luz (flare streaks) 

Las bandas de luz son una caracte- 
ristica que se encuentra desactivada por 
defecto. Estas bandas suelen ser hori- 
zontales o verticales y pueden em- 
plearse para producir la imagen de una 
explosion estelar (ver flare space2) o 
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del foco tfpico de un campo de futbol 
(flare sports). Las variables que contro- 
lan su funcionamiento son: 
streak_a_size, que controla el radio del 
flare, streak_a_color, con el que se es- 
pecifica el color del borde de la banda. 
streak_a_center_color, que indicara el 
color del centra de la banda, streakjr, 
que se usa para indicar la translucencia 
minima de la banda, streak_a_scale, en 
el que guardaremos un vector para in- 
dicar la escala de la banda en los ejes X 
e Y, y streak_a_rotate, que se empleara 
para rotar la banda. 

El lector habra observado el em- 
pleo de una 'a' en todas estas varia- 
bles. Esto quiere decir que dichas or- 
denes se limitan a la banda 'A' y que 
existe una segunda banda Uamada 'B' 
para la que hay otro juego de varia- 
bles que emplean la 'b'. Esto pode- 
mos comprobarlo examinando las lf- 
neas del flare sports, en el que se 
emplean las dos bandas y donde estas 
se giran 45 grados. 

Variables de uso general 

El tamafio global de cualquier flare 
entero puede controlarse con la varia- 
ble flare_scale_factor, cuyo valor por 
defecto es de 1 . Si ponemos un valor 
de 2 en esta variable el tamafio del flare 
se doblara y si colocamos un valor 0.5. 
se dividira por 2. Flare_rotate se em- 
plea para rotar el flare. Flare_bnght- 
ness (que guarda valores normalmente 
superiores a 1 ) se utiliza para ajustar el 
brillo global del flare y suele usarse 
cuando el flare ha quedado demasiado 
oscuro para la imagen. 

Main_flare_scale se utiliza para 
controlar la escala del flare primario y 
de sus brillos y glow. Ademas podemos 
hacer que la escala a ordenar no sea 










identica en los dos ejes, con lo cual 
conseguiremos un interesante efecto de 
achatamiento similar al logrado en el 
flare space2. 

Notas y trucos 

Lo explicado hasta aqui deberia ser 
suficiente para que los povmanfacos 
hagan sus propias escenas con este 
magnffico "ipas". Unicamente hay que 
recordar un par de cosas: 

1 ) Algunas variables precisan va- 
lores que oscilan entre y 1 y otras no. 
Si lo que haceis no funciona echad un 
vistazo a las flares predefinidas. Es la 
mejor manera de asegurarse del tipo de 
entrada que precisa cada variable. 

2) Podemos colocar mas de un fla- 
re en la escena. Para ello bastard con 
colocar otra sentencia con un nuevo va- 
lor para lightjoc y. por supuesto, con 
colocar otro include para LnsFlare. 

3) El flare que haya sido definido 
seguira a la fuente a la que este atado 
en una animacion pero, en algunos ca- 
sos, puede ser necesario emplear la 
sentencia "vrotate" del lenguaje esce- 
nico de POV. 

4) Si hay problemas con espejos 
debereis incrementar el valor de 
#max_tracejevel. 

5) Podeis encontrar proximas ver- 
siones de LnsFlare en el "site" de 
Nathan Kopp cuya visita os recomen- 
damos. Esta en la direccion 
http://www.grfn.org/~nkopp. En sus 
paginas, Kopp exhibe unas modifica- 
ciones de viejas obras de Douglas Muir 
y Dan Farmer.(hemos duplicado la de 
Muir anadiendo simplemente una fla- 
re, como hizo el mismo Kopp). 

6) Los flares no funcionaran si se 
emplea algiin tipo especial de camara. 
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Arte Espacial 




Este articulo se aparta un tanto de todo lo que es habitual en estas 

paginas pero creemos que por una vez valdra la pena hacer una 

excepcion. Todo empezo bastante inocentemente, buscando unos 

bitmaps planetarios por Internet, y acabo con un vistazo al arte espacial 

renderizado de la Nasa, una exploracion marciana con MapMaker, y un 

recorrido por todo el sistema solar de la mano del simulador de la Jet 

Propulsion Laboratory. 
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ste articulo bien po- 

Edria haber tenido un 
tftulo diferente co- 
mo por ejemplo; 
"Porque amo a In- 
ternet" o algo pare- 
cido. Si, en efecto. Tenemos por fin una 
conexion propia y no podemos com- 
prender como pudimos vivir antes sin 
ella. Sin duda ya estareis hartos de oir 
frases como esta, pero la verdad es que 
llega un momento en que toda esa pe- 
sada palabreria quiere decir algo: ren- 
dermanfacos; la Red es algo maravillo- 
so. Solo el navegar, el explorar, ya es 
algo fascinante. Uno salta de un sitio a 
otro, la mayoria de las veces sin hallar 
nada litil, pero otras encontrando la 
perla que hace que todo valga la pena. 
Y ademas, la perla encontrada suele te- 
ner links que tambien tienen su interes. 

Donde encontrar 
bitmaps planetarios 

El nuevo navegante ya no recuerda 
como encontro el Web de Thomas 
Constantine. El caso es que una de sus 
paginas, cuya direction es... 

w ww.lancs.ac.uk. /postgrad/tho- 
mascl/render/maps.htm 

...pronto demostro ser muy intere- 
sante. Alii habi'a un indice de mapas de 
planetas. Estaban la Tierra, Marte, Sa- 
turno, Urano, etc. Al pinchar en el link 
de "Earth", aparecio una pagina con 
datos globales sobre nuestro mundo y 
tambien una ventana que exhibfa un 
bitmap en proyeccion cih'ndrica simple 
de la Tierra. Al pinchar sobre ella se 
cargo una preciosa imagen jpg con una 
vista de toda la corteza terrestre y de su 
atmosfera y esta ha sido la textura que 
hemos empleado (en las pruebas de 



LnsFlare) para el planeta.Tierra. (.Co- 
mo? tQue hay alguien que no sabe lo 
que es un bitmap de proyeccion cih'n- 
drica? Pues se trata de una textura que 
emplearemos para recubrir a objetos de 
forma cih'ndrica o esferica. Las si- 
guientes son las h'neas con las que pue- 
de crearse a la "Tierra" desde POV: 
sphere { pos_tierra, radio 
pigment j 

image_map( tga "earth. tga" 
map_type 1 ) 

} 
rotate y*-50 



Desde luego la cosa es bien sencilla. 
Basta con crear una esfera y recubrirla 
con nuestro bitmap. Por si alguien aun 
no lo sabe, tendremos que emplear una 
proyeccion esferica (por defecto la pro- 
yeccion que realiza POV es plana y se 
extiende a lo largo del piano X-Y. Si 
queremos efectuar un mapeado esferi- 
co daremos el valor 1 a map_type). 
Usando la aplicacion esferica, la tex- 
tura indicada se mapeara adecuada- 
mente sobre la esfera que hace las ve- 
ces de planeta. El bitmap se enrollara 
sobre la esfera de manera que su hor- 
de superior quede 
en el polo norte y 
el inferior en el 
polo sur. La tex- 
tura recubrira 
completamente a 
la esfera una uni- 
ca vez sin que 
importe el tama- 
no que esta pueda 
tener (la palabra 
"once" no funcio- 
na con este tipo 
de proyeccion). 




Pero ahora volvamos con la navega- 
cion: despues de retornar al indice, en- 
contramos mapas similares que pueden 
ser usados para crear planetas con el 
aspecto de Marte, Jupiter, etc. El mapa 
de la Tierra es el producto resultante de 
miles de fotografi'as tomadas por una 
serie de satelites y por tanto es muy 
precise Otros, como el de Jupiter por 
ejemplo, han requerido bastante es- 
fuerzo infografico y arti'stico (emplean- 
do productos como Photoshop y otros) 
para conseguir el resultado final que 
podeis ver en el CD-ROM. En cual- 
quier caso estos mapas -que podeis en- 
contrar en el CD-ROM- pueden ser 
utilizados en simulaciones de viajes 
por el sistema solar o en escenas arti's- 
ticas, y pueden ser empleados por cual- 
quier programa 3D y no solo por POV. 

Arte planetario 

Despues de "bajamos" unas cuantas 
texturas de este tipo, retornamos al 
principio de la pagina y lefmos que mu- 
chos de los mapas que podfan encon- 
trarse antes en el Web de Thomas ya no 
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estaban, pero que habfa otras nuevas 
versiones en la pagina de un tal David 
Seal. Unas li'neas mas abajo se indicaba 
que David trabajaba en el Jet Propul- 
sion Lab (JPL) y que era responsable 
de gran parte del trabajo artfstico de la 
Nasa. ^Trabajo artistico de la Nasa? Y 
se afiadia que por esa razon los mapas 
de David eran mucho mas grandes y 
detallados que los del propio Thomas... 

Despues de pinchar en el link de Da- 
vid se tomo nota de la direccion 
siguiente... 

http://samadhi.jpl.nasa.gov/txmp 

Alii, aparte de muchos mas mapas, 
hay mucha informacion interesante. 
Eliminando el directorio txmp de la di- 
reccion accederemos a una pagina don- 
de hay enlaces a muchos lugares de in- 
teres. Comenzaremos comentando la 
existencia del "Nasa Mission Artwork" 
(en http://samadhi.jpl.nasa.gov/art). 
Aquf pueden verse preciosas escenas 
renderizadas de sondas espaciales via- 
jando por distintos puntos del sistema 
solar. En cada una de estas imagenes, se 
explica el punto de la mision que repre- 
senta la escena, las maniobras que lle- 
varon (o llevaran) allf a la nave, etc. Es- 
tas imagenes (o animaciones porque 
tambien las hay) fueron hechas con mul- 
titud de herramientas sobre plataformas 
SPARC y SGI (y parece ser que la mas 
importante es SPACE; un conjunto de 
programas disefiados para simular tra- 
yectorias de naves espaciales y que la 
nasa emplea para crear simulaciones de 
misiones en fase de proyecto). 

Otro lugar interesante es el "Solar 
System Surfaces", donde encontrare- 
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mos renders de tipo artistico de diver- 
sas superficies de diferentes objetos del 
sistema solar (el sol, asteroides, plane- 
tas...) Algunas de estas escenas (que po- 
deis admirar en el CD-ROM) son muy 
bellas. La direccion de esta pagina es... 
http://samadhi.jpl.nasa.gov/surfaces 

Pero continuenos con nuestro peri- 
plo. Otro enlace interesante de la pagi- 
na base es el "Spacecraft Models", en 
el directorio models, donde el infogra- 
fista hallara una lista de modelos 3D de 
las sondas de la Nasa (el problema es 
que hay muy pocas en formato dxf). 

Y finalmente, y ya para acabar con 
este sitio, tenemos el "Solar System Si- 
mulator". Parece ser que en junio del 
97 David Seal termino de adaptar el 
software de Space y lo conecto al 
World Wide Web. Este nuevo software 
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viene a ser un completo simulador del 
sistema solar, ya que puede renderizar 
cualquier punto del mismo teniendo en 
cuenta la position del observador, el 
punto hacia el que mira, la fecha, el 
campo de vista, etc. Las texturas em- 
pleadas en los planetas y otros cuerpos 
han sido obtenidas de diversas colec- 
ciones de fotos tomadas por sondas es- 
paciales y muchas de ellas pueden ser 
encontradas en la pagina de mapas que 
nemos comentado anteriormente. Se- 
gun se rumorea, este software podn'a 
estar disponible en un futuro proximo 
aunque, claro esta, no lo cataremos los 
infografistas de a pie (^alguien tiene 
aquf una SPARC?) 

Viaje fotografico 
por los planetas 

Perdido entre las paginas anteriores 
hay un link de un lugar llamado "Na- 
sa's Planetary Photojournal". Se trata 
de una enorme coleccion de fotograffas 
tomadas por sondas espaciales y que 
los aficionados a la astronomfa podran 
bajarse tranquilamente, ya que han sido 
cedidas al uso publico. Hay que preci- 
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sar que se trata de fotograftas y no de 
imageries retocadas y preparadas para 
ser empleadas infograficamente. El 
usuario podra solicitar las fotos direc- 
tamente (si conoce la codificacion em- 
pleada) o podra ir examinando las fotos 
de una sonda determinada, tras lo cual 
podra bajarla a su modesto PC. Hay 
que advertir, sin embargo, que muchas 
de estas fotos tienen una resolution 
grande o muy grande y que el ciber- 
nauta tendra que tener cuidado. so pena 
de perder el tiempo mirando una enor- 
me foto de la luna u otro cuerpo duran- 
te mas tiempo del que queniamos. Esta 
coleccion, que crece diariamente, tie- 
ne, en estos momentos de es 
cribir estas lfneas, algo 
menos de 700 fotos y su 
direction es: 

http://photojournal.jpl. 
nasa.gov 

Mapas marcianos 
a medida 

Otro lugar a visitar inexcusa- 
blemente es el Charlotte's Web Server, 
desde el que podremos aeceder a mu- 
chos lugares de interes. Su direccion es 
"http://www-pdsimage. jpl. nasa.gov" y 
desde alii podremos saltar al "Solar 
System Visualization Proyect" (que re- 
sulto ser horriblemente lento en las 
pruebas) o al "Planetary Data System 
Imaging Node". Este ultimo parece ser 
un sistema que mantiene y distribuye 
los archivos de fotos y datos de la Na- 




sa, a fin de que la comunidad cientffica 
tenga un facil acceso a ellos. A traves 
del "Node" puede accederse a un siste- 
ma de ficheros almacenados en CD- 
ROM por el que los expertos podran 
aeceder a datos de misiones historicas 
que, segiin parece, estaban a punto de 
perderse al no haber antes un sitio es- 
pecializado para ellas. Asf pues mu- 
chas de las imagenes almacenadas (hay 
algunas excepciones) podran ser acce- 
didas a traves del software de extrac- 
cion de datos del mismo Web, cuya di- 
reccion de Internet es: 

http://www-pdsimage.jpl.nasa.gov/PDS 
La cantidad de informacion almace- 
nada aquf es enorme. Por po- 
ner un ejemplo, solamente 
las fotos accesibles bajo 
el epfgrafe de las son- 
das Viking ya son 
50.000. Y hablando de 
las sondas Viking, des- 
de la direccion anterior 
podremos aeceder al "Mars 
Explorer" un programa por el 
que el usuario podra crear su propio 
mapa de la superficie marciana esco- 
giendo su propio factor de zoom, tama- 
no del mapa y sistema de proyeccion. 
Los mapas se confeecionaran gracias a 
un software Hamad o MapMaker que 
trabajara sobre las fotos de las misio- 
nes Viking para crear el mapa que de- 
seemos. Segun parece las fotos estan 
almacenadas en un sistema de CD- 
ROM y el programa nos permitira ae- 



ceder a ellas vfa Internet de una manera 
sumamente atractiva: pinchando en un 
mapa global de Marte pincharemos en 
la zona que nos interese. Entonces, tras 
una corta espera, MapMaker compon- 
dra un mapa con las fotos de la zona y 
nos lo enviara. Podremos entonces se- 
guir haciendo ampliaciones de la mis- 
ma manera o bien desplazarnos por la 
superficie marciana con las flechas de 
movimiento. Naturalmente llegara un 
momento en que. si seguimos amplian- 
do y ampliando, llegaremos al li'mite de 
resolucion de las fotos y no sera posi- 
ble continuar con el zoom (el uso de 
MapMaker es muy divertido. Pensad- 
lo: estamos viajando por Marte). 

La comodidad que proporciona Map- 
Maker al usuario es enornie (y. ademas. 
estos mapas si pueden ser empleados en 
escenas sinteticas). Ademas, segun se 
dice, es posible que en un futuro proxi- 
mo MapMaker soporte a otros cuerpos 
celestes como la Luna o Venus. 

Todo tiene un final 

Durante este viaje por la Red halla- 
mos texturas. fotos, animaciones, faqs. 
etc. El caudal de datos (y de siglas de 
organizaciones que los mantenian) no 
parecfa tener fin. Tambien encontramos 
otros "sites" de arte espacial hecho por 
usuarios (muchos de ellos de POV) e 
incluso naves espaciales para los mas 
diversos programas (incluyendo a Ima- 
gine y POV) pero ya hablaremos de 
ello en otro momento. 

En cuanto a los bitmaps planetarios. 
estos estan en formato jpg por lo que 
tendreis que convertirlos a TGA con al- 
guna utilidad como Alchemy o Photos- 
hop antes de emplearlos para crear 
vuestros planetas (todos ellos empiezan 
con la letra "t": Tearth. Tmars. etc). 



16 Rendermania 







*a* 



t 




El Foro del Lector 



Podeis rermtimos vueslros trabajos o consultas, bien por carta a la direction que 
figura en la segunda pdgina de PCmania, o via e-mail a rendermania.pcmania@hobbypress.es 



Hoy, 3D Studio 

Este mes -y salvo excepciones- casi todos los trabajos recibidos tienen 
en comun el haber sido creados con «3D Studio». Sin embargo, esta es la 
unica coincidencia, ya que en todo lo demas la diversidad es la norma en 
estas paginas en las que podremos ver soldados medievales, Mechs de 
combate, animaciones varias y otros trabajos de interes. 




Una de las mayores recompensas de nuestro trabajo consiste en leer las car- 
tas de lectores que nos envi'an animos, elogios. crfticas o, simplemente, el 
mensaje de que nuestros artfculos han servido de algo. Misivas como la de 
Julian I Ik-rni ( lama -que podeis encontrar en el foro- caen en este apar- 
tado. Julian, ya un viejo conocido de Rendermanfa. asegura haberse empo- 
llado la serie de artfculos dedicados a Imagine y ahora recibimos el fruto de 
su trabajo: el temible battlemech de la 
serie 20 1 , un mech de combate dise- 
fiado por Julian, completamente arti- 
culado y dispuesto para la lucha (que 
podreis encontrar en el CD-ROM). 
Julian nos pide una critica de su mech 
pero la verdad es que esta se nos hace 
muy diri'cil porque lo cierto es que nos 
ha gustado todo, incluso la textura. 
Los puntos de articulacion para el 201 
parecen correctamente dispuestos, la 
forma es interesante, el pie es muy 
majo y Julian de- 
muestra en su carta 
un buen conocimien- 
to de Imagine. Como 
puede verse en una de 
tus escenas, tu mech 
es mucho mas pesado 
que el nuestro. ^No 
resultant algo lento a 



pesar de su nuevo reactor Pullman 1 .6? 

Julian tambien pide la opinion de otros rendermanfacos sobre su trabajo y, como 
el movimiento se demuestra andando, el hace lo propio con algunos viejos cono- 
cidos como Di'az, Sendin, Torres y otros. ; Enhorabuena por tus Imagine-criatu- 
ras! (Naturalmente esperamos las proximas, ya sean de POV o Imagine). 
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Felipe Camacho Sillero nos 

envia uno de sus primeros 
trabajos realizado con «3D 
Studio*. Se trata de un mo- 
delo con el escudo de su 
equipo de futbol favorito; el 
Cordoba. Felipe ineluye ade- 
mas una sugerencia en su 
carta solicitando un curso de 
«3D Studio». Bien, por el 
momento no hay nada pre- 
visto sobre ello pero nunca 
hay que descartar ninguna 
posibilidad... 



4ntonin Abenza Fran nos envia 
tambien sus primeros trabajos hechos 
con el programa «3D Studio 4». Algu- 
nos de ellos -como el taller- tienen mas 
merito y trabajo del que parece (el ca- 
ble del soldador, las tenazas, etc) y por 
ello te enviamos la oportuna felicita- 
cion. Tan solo te diremos que deberias 
haber enviado una malla o un texto ex- 
plicativo que ayudara a certificar la au- 
torfa de tus imagenes. 





La primera animacion de Carles Vila era 
un recorrido casi completo por una casa. 
Desdichadamente dicha animacion ocupaba 
unos 62 Megas y por esa razon Carles ha 
debido contentarse con enviarnos otra que 
solo tiene unos 
2 Megas. (Por 
cierto, nuestro 
mas sentido 
pesame por los 
cuelgues que 
se producen en 
tu ordenador). 
Esta anima- 
cion esta reali- 
zada con «3D 
Studio 4». 
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Jose Miguel Dominguez 

Montesinos es otro render- 
mam'aco que tambien envi'a 
sus primeros trabajos con 
«3D Studio 4». Jose Miguel 
no ha enviado tampoco ni ma- 
llas ni excesivos datos acerca 
del proceso de creation de sus 
trabajos y por ello le envia- 
mos el oportuno tiron de ore- 
jas. Jose Miguel apunta en su 
carta algunas preguntillas: 
1) (,C6mo hacer que las 
superficies de «3D Studio» no 
queden tan perfectas? Como 
siempre hay diversos caminos 
pero casi todos pasan por em- 
pollarse bien el Materials edi- 
tor. Lo mas sencillo es aplicar 
algun bitmap con apariencia 
de metal corrofdo y eliminar 
los brillos de las superficies. Otro sistema menos utilizado 
es emplear algun Ipas de fractalizacion que desordene al 
azar (en un pequeno factor) los vertices. 

2) ^.Donde pueden encontrarse en Internet Ipas para «3D 
Studio»? Esto no es facil ya que la inmensa mayoria de los 
Ipas son de pago y no se distribuyen libremente (salvo en 
versiones recortadas). Prueba a mirar cada cietto tiempo en 
el Web de Avalon, donde tambien podras hallar objetos, 
texturas, informaciones diversas, etc. (En 
http://avalon.viewpoint.com o a traves de www.view- 
point.com). Otro lugar interesante es el 3dcafe en 
www.3dcafe.com 

3) tQue si se pueden conseguir imagenes de buena cali- 
dad con POV? Dios info... 



Hector de la Fuentc Pita nos envi'a, entre otros modelos, un soldado medieval creado con 
«3D Studio 3». Segun afirma Hector, casi todas las piezas del modelo -cuya malla podeis en- 
contrar en el CD-ROM- fueron construidas con la option Fit a partir de formas creadas desde 
el 2d Shaper. Para este modelo Hector solicita una ,jsevera? crftica. Bueno, las proporciones 
generates del soldado son correctas y este merece todo el reconocimiento que debe darse a 
cualquier modelo antropomorfico aceptablemente resulton. Quiza hubieras debido afiadirle al- 
gunas piezas sueltas (un faldelh'n, un peto, etc.) que hicieran las funciones de armadura ligera 
y haber aplicado al modelo actual una textura que recordara a las tfpicas cotas de malla de la 
epoca. Las manos tampoco son muy buenas pero es dificilfsimo hacer unas manos aceptables 
con tecnicas normales. 

El soldado llego con algo de retraso para la batalla (que de todos modos se quedo en escaramuza por falta de memoria) pero es posible 
que cuando haya orcos, este modelo pueda ser aprovechado (al igual que otros). 

En cuanto a tu sugerencia, todos los lectores de PCmam'a pueden formar sus propias colecciones de objetos a partir del material que se 
va publicando aqui todos los meses. Lo unico que queda es sugerir temas, lo cual ya esta previsto para el asunto de las portadas. Por lo de- 
mas la organization de los modelos segiin los temas podria ser algo problematica ya que requerirfa un tiempo del que ahora carecemos (y 
ademas habrfa que escribir sobre cosas que ya se habn'an comentado en numeros previos, lo cual no nos parece un ahorro de espacio). 
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Pedro Palazon Martinez nos envi'a algunas imageries 
creadas con «3D Studio 4» con las que pasa a formar parte 
de la cada vez mas extensa lista de rendermanfacos inf'o- 
graficamente activos. Pedro solicita alguna gui'a para me- 
jorar, y desde aquf te damos un consejo muy sencillo: prac- 
tica mucho el modelado y no emplees tantfsimos poli'gonos 
para algo que puede representarse igual con mallas mucho 
menos densas (basta con ver la columna del templo). En 
cuanto a tus sugerencias... 

1) Lo de incluir texturas de libre distribucion es una 
buena idea pero no hay tantas (de calidad) como imaginas. 
tQue te parecen las texturas planetarias que hemos ensena- 
do en el presente numero? 

2) En cuanto al debate, serfa muy dif'i'cil evitar que 
acabara reducido a una mera publicacion de opiniones (;no 
puede haber tiempo real!). En algiin momento han surgido 
temas que provocaban el envi'o de opiniones por parte de 
los lectores (para eso esta tambien 

el foro) pero no creemos conve- 
niente provocar debates porque si. 
Lo ideal para cualquier renderma- 
nfaco es practicar, crear cosas, e 
intercambiar conocimientos rela- 
cionados con cosas concretas. 

En cuanto a tus preguntas, la 
utilidad 3ds2pov puede convertir 
ficheros de 3D Studio a POV con 
casi total perfeccion, ya que se tra- 
ducen modelos, colores, position 
de las luces y de la camara, etc. La 
imagen generada en POV sera practicamente identica a la 
creada por 3D Studio salvo por lo referente a los bitmaps, si 
los hay. Lo contrario (POV a 3D Studio) no es posible en la 
inmensa mayorfa de los casos debido a que las primitivas de 
POV no se construyen con poli'gonos. Y para cuestiones ar- 
quitectonicas preferimos POV a 3D Studio (tu otra pregun- 
ta), aunque esto siempre es algo muy subjetivo. 



Borja Morales alias «3d reality* ha en- 
viado varias animaciones creadas con «3D 
Studio 4». Pero, desgraciadamente, uno de 
los ficheros del paquete (el reality.a03) lie- 
go estropeado y solo fue posible salvar a 
mago.avi. En esta animacion, Borja ha 
creado unas secuencias de gran realismo 
empleando el magni'fico mago creado por 
Juan Carlos Jimenez Mendez. En la peli- 
cula el mago corre, se detiene, prepara una 
bola de energfa magica y la lanza para, fi- 
nalmente, ejecutar un saludo ritual. Los re- 
sultados son sencillamente magni'ficos y en 
ellos se aprecia que, salvo en unos miniis- 
culos detalles, el movimiento del personaje 
es perfecto. El mago no sufre practicamen- 
te deslizamientos al correr (fijaos en la to- 





ma lateral) y pueden apreciarse bien los 
cambios de altura debidos a este ejercicio. 
Lo vjnico que desentona (en cuanto a nivel 
de realismo) son los movimientos de los 
pies del personaje cuando este ya se ha de- 
tenido y esta preparando y lanzando la bo- 
la magica (porque se producen unos desli- 
zamientos bastante raros). Pero, salvo este 
pequefio detalle, la animacion es extraor- 
dinaria. jEnhorabuena amigo Borja! 



Por varias razones tenemos que enviar un tiron de orejas a nues- 
tro amigo Oriol Bagan. Este lector nos ha enviado su primer traba- 
jo (con «Imagine 3.0») basado en un juego llamado Ballz. Pero, 
Oriol no ha incluido ni un solo render del modelo, razon por la cual 
no hay aquf ninguna foto del mismo. Ademas, tampoco diste la ex- 
tension adecuada (obj) al archivo, con lo cual al principio lo toma- 
mos por una imagen en algiin formato raro. 
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